Field of the Invention
The present invention relates to packet transmission in a cellular communications network, and in particular to the reporting of buffer status for uplink data packets from a wireless device to a base station. While it is described below in the context of an LTE (“long term evolution”) type of cellular network for illustration purposes and because it happens to be well suited to that context, those skilled in the communication art will recognize that the invention disclosed herein can also be applied to various other types of cellular networks.
Discussion of the Related Art
Universal mobile telecommunications system (UMTS) is a 3rd Generation (3G) asynchronous mobile communication system operating in wideband code division multiple access (WCDMA) based on European systems, global system for mobile communications (GSM) and general packet radio services (GPRS). The long term evolution (LTE) of UMTS is under discussion by the 3rd generation partnership project (3GPP) that standardized UMTS.
The 3GPP LTE is a technology for enabling high-speed packet communications. Many schemes have been proposed for the LTE objective including those that aim to reduce user and provider costs, improve service quality, and expand and improve coverage and system capacity. The 3G LTE requires reduced cost per bit, increased service availability, flexible use of a frequency band, a simple structure, an open interface, and adequate power consumption of a terminal as an upper-level requirement.
FIG. 1 is a block diagram illustrating network structure of an evolved universal mobile telecommunication system (E-UMTS). The E-UMTS may be also referred to as an LTE system. The communication network is widely deployed to provide a variety of communication services such as voice and packet data.
As illustrated in FIG. 1, the E-UMTS network includes an evolved UMTS terrestrial radio access network (E-UTRAN) and an Evolved Packet Core (EPC) and one or more user equipment. The E-UTRAN may include one or more evolved NodeB (eNodeB, or eNB) 20, and a plurality of user equipment (UE) 10 may be located in one cell. One or more E-UTRAN mobility management entity (MME)/system architecture evolution (SAE) gateways 30 may be positioned at the end of the network and connected to an external network.
As used herein, “downlink” refers to communication from eNodeB 20 to UE 10, and “uplink” refers to communication from the UE to an eNodeB. UE 10 refers to communication equipment carried by a user and may be also be referred to as a mobile station (MS), a user terminal (UT), a subscriber station (SS) or a wireless device.
An eNodeB 20 provides end points of a user plane and a control plane to the UE 10. MME/SAE gateway 30 provides an end point of a session and mobility management function for UE 10. The eNodeB and MME/SAE gateway may be connected via an S1 interface.
The eNodeB 20 is generally a fixed station that communicates with a UE 10, and may also be referred to as a base station (BS) or an access point. One eNodeB 20 may be deployed per cell. An interface for transmitting user traffic or control traffic may be used between eNodeBs 20.
The MME provides various functions including distribution of paging messages to eNodeBs 20, security control, idle state mobility control, SAE bearer control, and ciphering and integrity protection of non-access stratum (NAS) signaling. The SAE gateway host provides assorted functions including termination of U-plane packets for paging reasons, and switching of the U-plane to support UE mobility. For clarity, MME/SAE gateway 30 will be referred to herein simply as a “gateway,” but it is understood that this entity includes both an MME and an SAE gateway.
A plurality of nodes may be connected between eNodeB 20 and gateway 30 via the S1 interface. The eNodeBs 20 may be connected to each other via an X2 interface and neighboring eNodeBs may have a meshed network structure that has the X2 interface.
FIG. 2(a) is a block diagram depicting an architecture of a typical E-UTRAN and a typical EPC. As illustrated, eNodeB 20 may perform functions of selection for gateway 30, routing toward the gateway during a Radio Resource Control (RRC) activation, scheduling and transmitting of paging messages, scheduling and transmitting of Broadcast Channel (BCCH) information, dynamic allocation of resources to UEs 10 in both uplink and downlink, configuration and provisioning of eNodeB measurements, radio bearer control, radio admission control (RAC), and connection mobility control in LTE_ACTIVE state. In the EPC, and as noted above, gateway 30 may perform functions of paging origination, LTE-IDLE state management, ciphering of the user plane, System Architecture Evolution (SAE) bearer control, and ciphering and integrity protection of Non-Access Stratum (NAS) signaling.
FIGS. 2(b) and 2(c) are block diagrams depicting the user-plane protocol and the control-plane protocol stack for the E-UMTS. As illustrated, the protocol layers may be divided into a first layer (L1), a second layer (L2) and a third layer (L3) based upon the three lower layers of an open system interconnection (OSI) standard model that is well-known in the art of communication systems.
The physical layer, the first layer (L1), provides an information transmission service to an upper layer by using a physical channel. The physical layer is connected with a medium access control (MAC) layer located at a higher level through a transport channel, and data between the MAC layer and the physical layer is transferred via the transport channel. Between different physical layers, namely, between physical layers of a transmission side and a reception side, data is transferred via the physical channel.
The MAC layer of Layer 2 (L2) provides services to a radio link control (RLC) layer (which is a higher layer) via a logical channel. The RLC layer of Layer 2 (L2) supports the transmission of data with reliability. It should be noted that the RLC layer illustrated in FIGS. 2(b) and 2(c) is depicted because if the RLC functions are implemented in and performed by the MAC layer, the RLC layer itself is not required. The packet data convergence protocol (PDCP) layer of Layer 2 (L2) performs a header compression function that reduces unnecessary control information such that data being transmitted by employing Internet protocol (IP) packets, such as IPv4 or IPv6, can be efficiently sent over a radio (wireless) interface that has a relatively small bandwidth.
A radio resource control (RRC) layer located at the lowest portion of the third layer (L3) is only defined in the control plane and controls logical channels, transport channels and the physical channels in relation to the configuration, reconfiguration, and release of the radio bearers (RBs). Here, the RB signifies a service provided by the second layer (L2) for data transmission between the terminal and the E-UTRAN.
As illustrated in FIG. 2(b), the RLC and MAC layers (terminated in an eNodeB 20 on the network side) may perform functions such as Scheduling, Automatic Repeat Request (ARQ), and hybrid automatic repeat request (HARQ). The PDCP layer (terminated in eNodeB 20 on the network side) may perform the user plane functions such as header compression, integrity protection, and ciphering.
As illustrated in FIG. 2(c), the RLC and MAC layers (terminated in an eNodeB 20 on the network side) perform the same functions as for the control plane. As illustrated, the RRC layer (terminated in an eNodeB 20 on the network side) may perform functions such as broadcasting, paging, RRC connection management, Radio Bearer (RB) control, mobility functions, and UE measurement reporting and controlling. The NAS control protocol (terminated in the MME of gateway 30 on the network side) may perform functions such as a SAE bearer management, authentication, LTE_IDLE mobility handling, paging origination in LTE_IDLE, and security control for the signaling between the gateway and UE 10.
The NAS control protocol may use three different states; first, a LTE_DETACHED state if there is no RRC entity; second, a LTE_IDLE state if there is no RRC connection while storing minimal UE information; and third, an LTE ACTIVE state if the RRC connection is established. Also, the RRC state may be divided into two different states such as a RRC_IDLE and a RRC_CONNECTED.
In RRC_IDLE state, the UE 10 may receive broadcasts of system information and paging information while the UE specifies a Discontinuous Reception (DRX) configured by NAS, and the UE has been allocated an identification (ID) which uniquely identifies the UE in a tracking area. Also, in RRC-IDLE state, no RRC context is stored in the eNodeB.
In RRC_CONNECTED state, the UE 10 has an E-UTRAN RRC connection and a context in the E-UTRAN, such that transmitting and/or receiving data to/from the network (eNodeB) becomes possible. Also, the UE 10 can report channel quality information and feedback information to the eNodeB.
In RRC_CONNECTED state, the E-UTRAN knows the cell to which the UE 10 belongs. Therefore, the network can transmit and/or receive data to/from UE 10, the network can control mobility (handover) of the UE, and the network can perform cell measurements for a neighboring cell.
In RRC_IDLE mode, the UE 10 specifies the paging DRX (Discontinuous Reception) cycle. Specifically, the UE 10 monitors a paging signal at a specific paging occasion of every UE specific paging DRX cycle.
FIG. 3 illustrates diagrammatically the buffering of uplink user traffic in Layer 2 on the UE side. U-plane traffic as received from Layer 3 consists typically of IP packets 50 with payload 51 from upper application layers, to be processed by the logic 55 of the PDCP layer. These packets 50 form PDCP service data units (SDUs) transferred from upper layers and stored in a PDCP buffer 56. Each packet 50 has a header 52 which includes an IP header and possibly other header fields from an upper layer protocol such as the real time protocol (RTP) in the case of a voice over IP (VolP) application for example.
The PDCP protocol data units (PDUs) 60, 70 generated by the PDCP layer 55 are transferred to the RLC layer 80 where they are stored in an RLC buffer 81. Each PDCP PDU 60, 70 has a short header 61, 71 including a PDCP sequence number and an indication of a PDU type.
Some PDCP PDUs 60 (indicated in the short header 61) convey user traffic, usually in the form of one IP packet per PDU. The header 52 of this IP packet is compressed in the PDCP layer 55 (compressed header 62 shown in FIG. 3) by a header compression algorithm called RoHC (robust header compression). The PDCP layer may also encrypt the user data and add a message authentication code for integrity protection (MAC-I). The header compression is based on the fact that in an IP header many of the fields do not change dynamically. For example, during a VolP call the target IP address and the source IP address typically remain unchanged. Thus it is only necessary to include this type of information when it changes. RoHC schemes can take advantage of various kinds of redundancy in protocol headers, as is well known in the art. See, for example, the request for comments (RFC) 4995, “The RObust Header Compression (ROHC) Framework”, published in July 2007 by the Internet Engineering Task Force (IETF).
Other uplink PDCP PDUs 70 (as indicated in the short header 71) are PDCP control PDUs that convey control information, such as a PDCP status report on missing or acknowledged downlink PDCP SDUs following a handover. Such a status report is used by the peer PDCP layer in the eNodeB servicing the new cell to determine which PDCP SDUs should be retransmitted.
Another example of the control information is header compression control information, such as interspersed RoHC feedback generated by the header compression algorithm in order to secure robustness of the compression process. In order to cope with the scenario where a packet that indicates a change in a header field is missed, the receiver can send such RoHC feedback information to the sender, such that critical information, e.g. updates, is repeated. Thus the sender should compress the header as late as possible in order to make sure that it is possible to react on received RoHC feedback information. In FIG. 3, arrow 82 designates RoHC feedback as received by the UE 10 on a downlink channel and supplied to the RoHC algorithm of the PDCP layer 55 executed for the transmission of uplink user data.
The RLC layer 80 processes the PDCP PDUs to control data transfer in transparent, acknowledged or unacknowledged mode and to execute the relevant automatic repeat request (ARQ) procedures. The RLC PDUs for each logical channel are passed to the MAC layer 85 which adds MAC header information and performs other medium access functions, such as scheduling or hybrid ARQ (HARQ) processes.
One of the MAC signaling procedures implemented in the uplink transport channels is the buffer status reporting procedure. It is used to provide the serving eNodeB 20 with information about the amount of uplink data buffered in the UE 10. Such information, along with other information such as priorities allocated to different logical channels, is useful to the uplink scheduling algorithms run by the MAC layer of the eNodeB 20 to determine which UEs, or logical channels, should be granted radio resources at a given time. The buffer status information indicates the amount of data available for transmission. In UMTS, the scheduling information indicates the data stored in the RLC buffer 81, as illustrated by block 84 in FIG. 3, and the MAC layer requests the RLC layer to report the amount of data available such that the amount of data can be reported to the network in a buffer status report (BSR) included into certain uplink MAC PDUs.
In LTE however, header compression is used in order to reduce the amount of data by applying a specific coding of the IP header as specified by the RoHC algorithm. Thus the amount of data sent to the PDCP peer entity is typically bigger than the amount of data that is sent from the PDCP to the RLC entity. The need to insert PDCP control PDUs from time to time is another source of errors.
When RoHC is used, it does not seem to be possible for the transmitter to indicate the exact size of the data that remains to be transmitted, because it would need to be compressed beforehand. Especially the feedback information from the receiver can affect the size of the data. For the transmitter, it is not possible to know the exact size of the data after compression until the compression is performed and thus it is not possible to indicate the exact size of the buffer.
An object of the present invention is to improve the reliability of the amount of buffered data reported by a wireless device to a network when compression is used.